home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / faq / comp / object_f / part4 < prev    next >
Text File  |  1993-12-14  |  60KB  |  1,459 lines

  1. Newsgroups: comp.object,comp.answers,news.answers
  2. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nic.hookup.net!news.kei.com!sol.ctr.columbia.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!news
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Subject: Comp.Object FAQ Version 1.0.5 (12-13) Part 4/8
  5. Message-ID: <1993Dec14.044538.18285@midway.uchicago.edu>
  6. Followup-To: comp.object
  7. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  8. Sender: news@uchinews.uchicago.edu (News System)
  9. Organization: Geodesic Systems
  10. Date: Tue, 14 Dec 1993 04:45:38 GMT
  11. Approved: news-answers-request@MIT.Edu
  12. Lines: 1444
  13. Xref: senator-bedfellow.mit.edu comp.object:13851 comp.answers:2992 news.answers:15750
  14.  
  15. Archive-name: object-faq/part4
  16. Last-Modified: 12/13/93
  17. Version: 1.0.5
  18.  
  19. > Encore (Brown University)
  20. email:bpe@browncs.brown.edu
  21.  
  22. Encore is an object-oriented database system targeted at large scale
  23. software engineering applications which are involved in data modeling.
  24. It was developed at Brown University in the late 1980s.  It is notable
  25. for its special support for long-lived (ie. cooperative) transactions,
  26. popular in design applications, and its support for class versioning.
  27. Objects are never converted, rather, classes are versioned, and the
  28. user can specify filters to make old-style instances appear as new
  29. instances to new applications (and vice versa).
  30.  
  31.  
  32. References/Additional Information:
  33.  
  34.  [] Mary F. Fernandez. OBSERVER: A storage system
  35.     object-oriented applications. Technical Report CS-90-27,
  36.     Brown University, Providence, RI, 1990.
  37.  
  38.  [] Mark F. Hornick and Stanley B. Zdonik. A shared, segmented
  39.     memory system for an object-oriented database. ACM
  40.     Transactions on Office Information Systems, 5(1):70--95,
  41.     January 1987.
  42.  
  43.  [] Andrea H. Skarra and Stanley B. Zdonik. Type evolution in an
  44.     object-oriented database. In Research Directions in
  45.     Object-Oriented Programming, MIT Press Series in Computer
  46.     Systems, pages 393--415. MIT Press, Cambridge, MA, 1987. An
  47.     early version of this paper appears in the OOPSLA '86
  48.     proceedings.
  49.  
  50.  [] Andrea H. Skarra and Stanley B. Zdonik. Concurrency control
  51.     for cooperating transactions in an object-oriented database.
  52.     In Won. Kim and Frederick H. Lochovsky, editors,
  53.     Object-Oriented Concepts, Databases and Applications.
  54.     Addison-Wesley, Reading, MA, 1989.
  55.  
  56. FTP: Complete source can be found in wilma.cs.brown.edu/pub/encore.tar.Z
  57. See also APPENDIX E.
  58.  
  59.  
  60. > Exodus (University of Wisconsin)
  61.  
  62. EXODUS is a DBMS from the University of Wisconsin.  An overview,
  63. excerpted from the abstract of [CDG+90] reads:
  64.  
  65.     EXODUS,   an   extensible database    system  project that is
  66.     addressing  data management problems  posed  by  a variety of
  67.     challenging new applications.  The  goal of the project is to
  68.     facilitate   the   fast    development of   high-performance,
  69.     application-specific  database  systems.     EXODUS  provides
  70.     certain  kernel facilities,   including  a versatile  storage
  71.     manager.  In addition, it provides an architectural framework
  72.     for building  application-specific database systems; powerful
  73.     tools   to  help  automate the  generation   of such systems,
  74.     including  a   rule-based query optimizer generator    and  a
  75.     persistent  programming  language;  and libraries  of generic
  76.     software components (e.g., access methods) that are likely to
  77.     be useful for many application domains.
  78.  
  79. The programming language is called E, an extension of C++. [RC89]
  80.  
  81. REFERENCES:
  82. (see "ftp.cs.wisc.edu:exodus/bibliography" for a complete list)
  83.  
  84. [CDG+90] Michael J. Carey, David J. DeWitt, Goetz Graefe,
  85.          David M. Haight, Joel E. Richardson, Daniel T. Schuh,
  86.          Eugene J. Skekita, and Scott L. Vandenberg. The EXODUS
  87.          extensible DBMS project:  An overview. In Stanley B.
  88.          Zdonik and David Maier, editors, Readings in
  89.          Object-Oriented Database Systems, Data Management
  90.          Series. Morgan Kaufmann, San Mateo, CA, 1990. Also
  91.          available as WISC-CS-TR 808.
  92.  
  93. [CDRS89] Michael J. Carey, David J. DeWitt, Joel E. Richardson,
  94.          and Eugene J. Skekita. Storage management for objects
  95.          in EXODUS. In Won. Kim and Frederick H. Lochovsky,
  96.          editors, Object-Oriented Concepts, Databases and
  97.          Applications, chapter 14. Addison-Wesley, Reading, MA,
  98.          1989. After Carey et al. Object and File Management in
  99.          the EXODUS Database System, Proceedings of the Twelveth
  100.          International Conference on Very Large Data Bases,
  101.          1986.
  102.  
  103. [GD87]   G. Graefe and D. DeWitt. The EXODUS optimizer
  104.          generator. In U. Dayal and I. Traiger, editors,
  105.          Proceedings of the SIGMOD International Conference on
  106.          Management of Data, San Francisco, CA, May 1987.
  107.  
  108. [RC89]   Joel E. Richardson and Michael J. Carey. Persistence in
  109.          the E language:  Issues and implementation. Software --
  110.          Practice and Experience, 19(12):1115--1150, December
  111.          1989.
  112.  
  113.  
  114. FTP: source code, documentation and a complete bibliography can be
  115.      found at ftp.cs.wisc.edu:exodus/
  116.  
  117. See also APPENDIX E.
  118.  
  119.  
  120. On Schema Evolution (from original survey):
  121. No solution for the problem of schema evolution is provided.
  122. Emulation is rejected by the authors, who claim that the addition of a
  123. layer between the EXODUS Storage Manager and the E program would
  124. seriously reduce efficiency.  Automatic conversion, whether lazy or
  125. eager, is also rejected, as it does not mesh well with the C++ data
  126. layout.  To implement immediate references to other classes and
  127. structures, C++ embeds class and structure instances within its
  128. referent.  The resulting change in the size of the object might
  129. invalidate remote pointer references.
  130.  
  131.         Joel E.  Richardson and Michael J.  Carey.  "Persistence
  132.         in the E language: Issues and Implementation."  Appeared
  133.         in "Software -- Practice and Experience",
  134.         19(12):1115-1150, December 1989.
  135.  
  136.  
  137. > Machiavelli (University of Pennsylvania)
  138.  
  139. Machiavelli is a statically-typed programming language developed
  140. at the University of Pennsylvania. Its most outstanding innovation 
  141. is the use of conditional typing scheme in its type inference system. 
  142. It does not address type evolution.
  143.  
  144. [communication with limsoon@saul.cis.upenn.edu]
  145.  
  146. [Note: Machiavelli is included in this summary because it
  147.        previously incorporated persistence in its data model.]
  148.  
  149.  
  150.  
  151. > MOOD4-PC: Material's/Miniature Object-Oriented Database Prototype for
  152.              NEC/IBM-PC
  153.  
  154. is an object-oriented database system(OODBS) program developed in the
  155. course of our research project MOOD. The aim of the project MOOD is to
  156. develop a material database system to handle raw material data which
  157. are produced and accumulated in materials research and referred to by
  158. material experts when they face scientific or engineering problems
  159. where the expected behavior of particular materials in particular
  160. environments are crucial importance. We all know that the conventional
  161. database systems do not fulfill this requirement, though they serves
  162. well for bibliographic databases or fact databases which deals with
  163. the standard properties of standard materials.
  164.  
  165. MOOD4-PC is written in Arity/Prolog and available in source and
  166. executable form via anonymous ftp from:
  167.  
  168.    ~/pub/mood/mood4
  169.    at mood.mech.tohoku.ac.jp [130.34.88.61]
  170.    
  171.     ~/pub/database/mood
  172.     at ftp.uu.net [192.48.96.9]
  173.  
  174.     ~/pub/computing/databases/mood
  175.     at src.doc.ic.ac.uk [146.169.2.1]
  176.  
  177. Although it is true enough to say that MOOD4 is a general purpose
  178. OODBS, it may be appropriate to point out that MOOD4 is significantly
  179. different from what is generally meant by the term, the
  180. Object-Oriented Database System.
  181.  
  182. That is, OODBSs, in general, consist of two parts:
  183.  
  184.    (1) Disk storage manager
  185.    (2) Database language to define and manipulate data objects to
  186.        be stored to and retrieved from the disk.
  187.  
  188. The database language of OODBS is akin to the object-oriented
  189. programming language such as Smalltalk or C++. You can enjoy the full
  190. versatility of these general purpose programming language in writing
  191. application programs with the database language.
  192.  
  193. As apparent from these, OODBSs, in general, are for programmers who
  194. write application programs which serve end users' needs. MOOD, on the
  195. other hands, is not; it is for end users. It is provided with a user
  196. interface named the object editor or OE in short. With OE, we can;
  197.  
  198.   (1) Edit class definition objects and save them. This replaces the
  199.       data definition language.
  200.  
  201.   (2) Edit data objects and save them.
  202.  
  203.   (3) Create query objects, let the system select data objects which
  204.       match the queries, and browse them.
  205.  
  206. In the other words, we can do everything necessary to manage and use
  207. database with OE. MOOD, therefore, needs no programming language and,
  208. in fact, has none. In this regard, MOOD may better be categorized to
  209. the OODBS application.
  210.  
  211. The architecture of MOOD as such is the consequence of the nature of
  212. information to be dealt with in material database. If we describe the
  213. nature with a single word, "variety" will be the one most appropriate. 
  214. No fixed data structure can handle a handful of material data because
  215. their contents differ from one to another. The feature of OODBS
  216. relevant here is not the intimacy with programming languages but the
  217. flexibility of data structure which allows us to construct data
  218. objects with a variety of structures which match the variety in the
  219. information to be dealt with. Upon inputting and retrieving data
  220. objects, end users are forced to face this variety in data structure
  221. since significant information is born in the structures of individual
  222. representations.
  223.  
  224. Yet, we say that MOOD is a general purpose OODBS. This is not in the
  225. sense that we can develop application programs on it, but in the
  226. sense that it generally supports the essential capabilities of OODBS;
  227.  
  228.   (1) The abstract data type.
  229.  
  230.   (2) The nesting of structured data objects.
  231.  
  232.   (3) The class hierarchy.
  233.  
  234.   (4) The inheritance of attributes along the hierarchy.
  235.  
  236.   (5) Matching between objects along their structures with the
  237.       knowledge of the class hierarchy.
  238.  
  239. For additional features of MOOD4, please consult its manual available
  240. with the program. Although they are biased to the processing of
  241. material data (or, more generally, scientific and technical data),
  242. MOOD with these capabilities can be used in any application domain at
  243. least by the stage where you are to examine how well the pieces of
  244. information of interest are represented in OODBS and how well specific
  245. items of interest are discriminated out from the database as such.
  246.  
  247. Questions and suggestions on this software which are ever welcome
  248. indeed may be addressed to;
  249.  
  250.      Noboru Ono                                             
  251.      Dept. of Machine Intelligence and Systems Engineering, 
  252.      Faculty of Engineering, Tohoku University.            
  253.      Tel:++22-216-8111,
  254.      Fax:++22-216-8156,
  255.      E-mail:ono@mood.mech.tohoku.ac.jp
  256.  
  257.  
  258.  
  259.  
  260. > OBST/STONE (Forschungszentrum Informatik [FZI], Karlsruhe, Germany)
  261.  
  262. The OBject System of Stone --- OBST
  263.  
  264. The persistent object management system OBST was developed by
  265. Forschungszentrum Informatik (FZI) as a contribution to the STONE
  266. project. This project (supported by grant no. ITS8902A7 from the
  267. BMFT, i.e. the German Ministry for Research) aims at the development
  268. of a software engineering environment for education purposes and is
  269. carried out as a joint project of nine german universities and
  270. research institutions.
  271.  
  272. An essential feature of STONE is that the object oriented paradigm 
  273. is pursued consequently as a key concept. OBST is the common persistent
  274. object store for all tools within the STONE environment. 
  275.  
  276.  
  277.  Data Model
  278.  ---------
  279.  
  280. The OBST data model can be characterized by the following properties:
  281.  
  282.  * Schema definition language syntactically similar to C++
  283.  * Support of multiple inheritance
  284.  * Generic classes
  285.  * Abstract classes and methods
  286.  * Distinction between public, protected, and private methods
  287.  * Redefinition of methods
  288.  * Overloading of methods
  289.  
  290.  Schemas and Containers
  291.  ----------------------
  292.  
  293. Schemas are compiled by the OBST schema compiler. The compilation
  294. results are instances of classes of the meta schema. From these
  295. instances in a next step interfaces to different programming languages
  296. can be generated. At present the C++ language binding is implemented,
  297. interfaces to Lisp and other languages are planned.
  298.  
  299. Objects are stored in so-called containers. The container an object
  300. belongs to is determined at the time of object creation and fixed
  301. throughout the object's lifetime. Containers are the units of 
  302. clustering, synchronization, and recovery. Objects can be referenced
  303. by other objects across container boundaries.
  304.  
  305.  Incremental Loading
  306.  -------------------
  307.  
  308. OBST provides a mechanism to incrementally load methods. This enables
  309. programs to deal with objects whose type is defined after the program 
  310. itself has been developed. This is useful in systems that provide for 
  311. inheritance and it supports schema evolution. We used it e.g. for
  312. programs that interpret the object base and call methods of the
  313. found objects (for example the below mentioned browser).
  314.  
  315.  Prototype
  316.  ---------
  317.  
  318. Since end 1990 the first prototype of OBST is available and is shipped
  319. to interested universities and research institutions. The current
  320. version is publicly available via FTP (see below) since March '92.
  321. Our current mailing list (see below) comprises about 150 persons.
  322.  
  323. The system comes with the schema compiler, a library of predefined
  324. classes (like Set<Entity>, List<Entity>, String, ...), a graphical
  325. object browser (more a shell than a browser), the structurer and
  326. flattener (STF), tclOBST, and all manuals. For STF and
  327. tclOBST see below.
  328.  
  329.  Structurer and Flattener
  330.  ------------------------
  331.  
  332. This is a tool to build objects from bytestrings and flatten objects
  333. down to bytestrings. It is intended to be used when coupling UNIX
  334. tools to the object management system. The user defines a grammar that
  335. describes her objects. Afterwards, the structurer parses an ascii 
  336. text according to the given grammar and creates an OBST object
  337. structure that represents the corresponding parse tree.
  338. The flattener does the inverse transformation, that means it generates
  339. an ascii text from a given OBST object structure according to the given
  340. grammar.
  341.  
  342.  tclOBST
  343.  -------
  344.  
  345. tclOBST is a library which provides an embedding of OBST into the
  346. interactive tool command language tcl, developed by John Ousterhout
  347. at the University of Berkeley.
  348. Based on the standard tcl shells, which are also comprised in the
  349. tclOBST distribution, tclOBST offers interactive access to the complete
  350. functionality modeled by OBST schemata.
  351.  
  352.  
  353.  System Requirements
  354.  -------------------
  355.  
  356. For the prototype's installation a C++ compiler (GNU g++ 1.37 or 
  357. later 1.4* or 2.3.3 or AT&T 2.0/2.1/3.01) and the X-Windows system 
  358. (currently X11R4 or X11R5) for the graphical tools are required. 
  359. Installation is well-tried on SUN 4/* systems and should be no problem 
  360. on other UNIX machines, too.
  361.  
  362.  --------------------------------------------------------------------
  363.  
  364. For more information please mail to:
  365.  
  366.                 Forschungszentrum Informatik (FZI)
  367.                        STONE Projekt
  368.                  Haid-und-Neu-Strasse 10-14
  369.                      D-76131 Karlsruhe
  370.                           Germany
  371.  
  372. or email to:  stone@fzi.de
  373.  
  374. Phone:        ++49-721-9654-601
  375. Fax:          ++49-721-9654-609
  376. Teletex:      721 190 fziKA
  377.  
  378. The OBST system is available via anonymous FTP from ftp.fzi.de
  379. [141.21.4.3]. The system can be found in the directory /pub/OBST/OBST3-3.3
  380.  
  381. Sites interested in getting information about new OBST developments
  382. are welcome to register in our mailing list. This can be done
  383. by sending an email with subject "obst-mailing-list" and contents
  384. "SUBSCRIBE <firstname> <surname> <email-adr>" to stone@fzi.de.
  385. If the subscription was successful you will receive a confirmation.
  386.  
  387. Bug reports should contain a small example program with which the
  388. bug can be reproduced, or at least a detailed description of the
  389. observed phenomenon. 
  390.  
  391. Besides bug reports we are strongly interested in all experiences
  392. our users make with OBST (e.g. sufficiency of data model, performance,
  393. ...) and in our users' application areas and the applications as
  394. well. So, please don't hesitate to send us a short note.
  395.  
  396. Best regards and happy OBST programming.
  397.  
  398.    The OBST Team
  399.  
  400.  
  401.  ---
  402.  
  403. BTW "Obst" is the German word for "fruit",
  404.     so have a fruitful time with OBST!
  405.  
  406.  
  407. > Ode
  408.  
  409.                                  Ode 2.0
  410.                        An Object-Oriented Database
  411.  
  412.        C++ Compatible, Fast Queries, Complex Application Modeling,
  413.        Multimedia Support, and more
  414.  
  415. See APPENDIX E, Databases, for description.
  416.  
  417.  
  418. > Oggetto, University of Lancaster, UK.
  419.  
  420. Developed at the University of Lancaster, UK.  Summary NYI.
  421.  
  422. "Oggetto: An Object Oriented Database Layered on a Triple Store",
  423. J.A. Mariani, The Computer Journal, V35, No 2, pp108-118, April 1992.
  424.  
  425.  
  426. > ORION (Now marketed as ITASCA)
  427.  
  428. ORION was a prototype OODBMS developed at MCC, an American consortium by Won
  429. Kim and his group.  Won Kim has left MCC and formed a new company, UniSQL, in
  430. Austin, with a new product of the same name.
  431.  
  432. See also entry under "ITASCA".
  433.  
  434. REFERENCES:
  435.  
  436. I have found nearly a dozen papers published by the ORION folks.
  437. Overviews at various stages in its development and commercialization
  438. can be found in:
  439.  
  440. [KBGW91] Won Kim, N. Ballou, J.F. Garza, and D.; Woelk. A
  441.          distributed object-oriented database system supporting
  442.          shared and private databases. ACM Transactions on
  443.          Information Systems, 9(1):31--51, January 1991.
  444.  
  445. [KGBW90] W. Kim, J.F. Garza, N. Ballou, and D. Woelk.
  446.          Architecture of the orion next-generation database
  447.          system. IEEE Transactions on Knowledge and Data
  448.          Engineering, 2(1):109--24, March 1990.
  449.  
  450. [KBCG89] Won Kim, Nat Ballou, Hong-Tai Chou, and Darrell Garza,
  451.          Jorge F. Woelk. Features of the ORION object-oriented
  452.          database system. In Won. Kim and Frederick H.
  453.          Lochovsky, editors, Object-Oriented Concepts, Databases
  454.          and Applications, chapter 11. Addison-Wesley, Reading,
  455.          MA, 1989.
  456.  
  457. [KBC+88] Won Kim, N. Ballou, Hong-Tai Chou, J.F. Garza,
  458.          D. Woelk, and J. Banerjee. Integrating an
  459.          object-oriented programming system with a database
  460.          system. In Proceedings of the ACM Conference on
  461.          Objected-Oriented Programming:  Systems, Languages and
  462.          Applications (OOPSLA), pages 142--152, San Diego, CA,
  463.          September 1988. Published as ACM SIGPLAN Notices
  464.          23(11).
  465.          [Pointers to the previous papers documenting each of the
  466.           advanced features listed above are cited therein.]
  467.  
  468.  
  469. The paper most relevant to the issue of schema evolution is the
  470. following:
  471.  
  472. [BKKK87] J. Banerjee, W. Kim, H-J. Kim, and H.F. Korth.
  473.          Semantics and implementation of schema evolution in
  474.          object-oriented databases. In U. Dayal and I. Traiger,
  475.          editors, Proceedings of the SIGMOD International
  476.          Conference on Management of Data, San Francisco, CA,
  477.          May 1987.
  478.  
  479.  
  480. You might also like to look at Kim's book, which provides a good
  481. introduction to OODBMS, while focusing on the ORION work:
  482.  
  483. [Kim90]  Won Kim. Introduction to Object-Oriented Databases.
  484.          Computer Systems. MIT Press, Cambridge, MA, 1990.
  485.  
  486.  
  487. > OTGen (Carnegie Mellon University/UMass Amherst)
  488.  
  489. OTGen is a design for a system to support schema evolution in
  490. object-oriented databases.  The chief contribution of OTGen is support
  491. for programmer extensibility of transformation functions to allow a
  492. system to support a wide range of schema changes, not just those that
  493. can be easily automated.  While OTGen was never implemented, it is
  494. based on the implementation of TransformGen, a system to support the
  495. evolution of the specialized databases used by Gandalf programming
  496. environments.  For more information on OTGen and TransformGen, please
  497. see: 
  498.  
  499. Barbara Staudt Lerner and A. Nico Habermann, "Beyond Schema Evolution
  500.     to Database Reorganization", in Proceedings of the Joint ACM 
  501.     OOPSLA/ECOOP '90 Conference on Object-Oriented Programming:
  502.     Systems, Languages, and Applications, Ottawa, Canada, October
  503.     1990, 67-76. 
  504.  
  505. Barbara Staudt, Charles Krueger, and David Garlan, TransformGen:
  506.     Automating the Maintenance of Structure-Oriented Environments, 
  507.     Computer Science Department Carnegie-Mellon University, Technical 
  508.     Report CMU-CS-88-186, November 1988.
  509.  
  510. David Garlan, Charles W. Krueger, and Barbara J. Staudt, "A Structural
  511.     Approach to the Maintenance of Structure-Oriented Environments",
  512.     in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
  513.     Symposium on Practical Software Development Environments, Palo
  514.     Alto, California, December 1986, 160-170.
  515.  
  516. Contact:
  517. Barbara Lerner
  518. blerner@cs.umass.edu
  519.  
  520.  
  521. > VODAK
  522.  
  523. Research in the framework of VODAK focuses on an extensible data
  524. model and database programming language, an advanced transaction
  525. model, object-oriented query language, and support for multimedia data.
  526.  
  527. The VODAK Data Model Language VML
  528.  
  529. Usually database models lack mechanisms for extending them with
  530. additional modeling primitives. This limitation does not allow the
  531. adaptation of the models for specific application needs, e.g. database
  532. integration, multimedia document handling, hypertext modeling, etc.
  533.  
  534. The VODAK Model Language VML  homogeneously integrates the concept of
  535. metaclasses and the separation of types and classes with other
  536. object-oriented concepts such as properties, methods, inheritance, and
  537. object identity. Complex nested data structures can be defined using
  538. the set, array, tuple, and dictionary type constructors. VML supports
  539. its own programming language for implementing methods, specifying
  540. transactions and an ad hoc query language.
  541.  
  542. In VML classes are used to organize a set of objects corresponding to
  543. real world entities and relationships between them. Object types define
  544. the structure of objects and the operations defined on these
  545. structures.  They are associated with classes in order to determine the
  546. structure and behavior of the class' instances. Metaclasses are first
  547. class objects whose instances are classes. Metaclasses are associated
  548. with three object types: an (optional) own-type extending their own
  549. behavior, an instance-type specifying the behavior of their instances
  550. (which are classes), and an  instance-instance-type specifying the
  551. behavior of the instances of their instances.  Metaclasses can be
  552. organized in an instantiation hierarchy of arbitrary depth.
  553.  
  554. This approach leads to an open, adaptable data model which provides for
  555. the specification of additional modeling primitives at a meta layer of
  556. the database schema. The concept of metaclasses and the separation of
  557. classes and types allow to determine the structure and behavior of
  558. objects and the individual inheritance behavior via semantic
  559. relationships between arbitrary objects already at the meta layer
  560. independently from the specifications given at the application layer
  561. for the application specific classes.
  562.  
  563.  
  564. The VODAK Transaction Model
  565.  
  566. In VODAK, we focus on two specific problems of transaction management.
  567.  
  568. 1. Operations to read and edit (hyper)documents are typically complex,
  569. interactive and of long duration. A high degree of concurrency is
  570. required to reduce the number and length of times a transaction is
  571. blocked.
  572.  
  573. 2. A publication environment has to handle existing database systems
  574. for using and modifying remote information and documents.  Transaction
  575. managers of existing systems, i.e. concurrency control and recovery,
  576. have to be integrated in a transparent way utilizing the functionality
  577. of existing managers.
  578.  
  579. Our transaction model is based on open nested transactions. Compared to
  580. conventional flat transactions, nested transactions allow more
  581. concurrency and are more flexible for recovery.  A nested transaction
  582. is a tree-like structure, dynamically built up by the call of
  583. subtransactions until a bottom implementation level is encountered.
  584.  
  585. We extended the open nested model from a fixed calling hierarchy of
  586. operations in a layered system (multi-level transactions) to an
  587. arbitrary calling hierarchy of operations in an object-oriented system.
  588. Commutativity of operations is applied to system defined VODAK methods,
  589. and to methods of user defined object types.  For the second type of
  590. operations, we developed a framework to specify commutativity and
  591. inverse operations in VML.
  592.  
  593. Query Processing
  594.  
  595. Although nearly all object-oriented data models proposed so far include
  596. behavioral aspects, most object-oriented query languages, algebras and
  597. query optimization strategies simply adapt relational concepts since
  598. they focus on the complex structures of objects and neglect the
  599. behavior. We claim that this approach is not sufficient since it does
  600. not reflect the much richer semantics methods can carry which have to
  601. be taken into account for really efficient query processing. The quite
  602. straightforward approach we consider is to integrate methods in an
  603. algebraic framework for query processing and to make there partial
  604. knowledge about methods available in the form of equivalences. We
  605. integrate algebraic set operators with methods defined in database
  606. schemas within an object-oriented data model. We investigate the impact
  607. on the architecture of the query processor when the algebra becomes an
  608. extendible component in query processing.
  609.  
  610. Multimedia Support
  611.  
  612. The V3 Video Server was built as a demonstration showing a multimedia
  613. application developed on top of the VODAK database management system.
  614. The V3 Video Server allows a user to interactively store, retrieve,
  615. manipulate, and present analog and short digital video clips. A video
  616. clip consists of a sequence of pictures and corresponding sound.
  617. Several attributes like author, title, and a set of keywords are
  618. annotated.
  619.  
  620. In the future, the VODAK DBMS will be enhanced with new built-in
  621. functionality for multimedia datatypes. Therefore, existing components
  622. of VODAK must be changed and new ones must be added to support time
  623. dependencies, high data volumes, and user interaction.
  624.  
  625. Query Processing
  626.  
  627. Although nearly all object-oriented data models proposed so far include
  628. behavioral aspects, most object-oriented query languages, algebras and
  629. query optimization strategies simply adapt relational concepts since
  630. they focus on the complex structures of objects and neglect the
  631. behavior. We claim that this approach is not sufficient since it does
  632. not reflect the much richer semantics methods can carry which have to
  633. be taken into account for really efficient query processing. The quite
  634. straightforward approach we consider is to integrate methods in an
  635. algebraic framework for query processing and to make there partial
  636. knowledge about methods available in the form of equivalences. We
  637. integrate algebraic set operators with methods defined in database
  638. schemas within an object-oriented data model. We investigate the impact
  639. on the architecture of the query processor when the algebra becomes an
  640. extendible component in query processing.
  641.  
  642. The VODAK Prototype
  643.  
  644. The system architecture consists of a central database environment and
  645. several external database environments to which the user wants to have
  646. integrated access. Each of these environments consists of an object
  647. manager, a message handler, a transaction manager, and a communication
  648. manager. In addition to these components an external database
  649. environment includes a database interface module which realizes the
  650. access to an external database system.
  651.  
  652. The DBMS components are currently built on top of DAMOKLES and will be
  653. in the near future on top of ObjectStore.
  654.  
  655. A first version of a C++ based prototype of VODAK is available for Sun
  656. Sparc Stations under certain conditions.  It implements all the
  657. features specified in including e.g. metaclasses, transactions, and
  658. remote message execution.
  659.  
  660. References
  661.  
  662. P. Muth, T. Rakow, W. Klas, E. Neuhold:  A Transaction Model for an
  663. Open Publication Environment.  A. K. Elmagarmid (Ed.): Database
  664. Transaction Models for Advanced Applications. Morgan Kaufmann
  665. Publishers, San Mateo, Calif., 1992.
  666.  
  667. Wolfgang Klas, Karl Aberer, Erich Neuhold Object-Oriented Modeling for
  668. Hypermedia Systems using the VODAK Modeling Language (VML) to appear
  669. in: Object-Oriented Database Management  Systems, NATO ASI Series,
  670. Springer Verlag Berlin Heidelberg, August 1993.
  671.  
  672. Karl Aberer, Gisela Fischer Object-Oriented Query Processing: The
  673. Impact of Methods on Language, Architecture and Optimization
  674. Arbeitspapiere der GMD No. 763, Sankt Augustin, July 1993.
  675.  
  676. T.C. Rakow, P. Muth The V3 Video Server: Managing Analog and Digital
  677. Video Clips, Sigmod 93, Washington, DC.
  678.  
  679. For further information contact
  680.  
  681. {aberer,muth,rakow,klas}@darmstadt.gmd.de
  682.  
  683.   GMD-IPSI                                             
  684.   Dolivostr. 15                                                           
  685.   D-64293 Darmstadt
  686.   GERMANY    
  687.                                     
  688.   FAX: +49-6151-869 966   
  689.  
  690.  
  691. Commercial Systems
  692. __________________
  693.  
  694. > ArtBASE  (Object-Oriented Data Model)
  695.  
  696. by:     ArtInAppleS Ltd.
  697.         Kremelska 13
  698.         845 03 Bratislava
  699.         SLOVAKIA
  700.         Phone: x42-7-362-889
  701.         fax:   x42-7-777 779
  702.         EMail: artbase.support@artinapples.cs
  703.  
  704. Distributor for Germany:
  705.         ARS NOVA Software GmbH
  706.         Stettener Strasse 32/3
  707.         73732 Esslingen a.N.
  708.         Germany
  709.         Phone: x49-711 3704001
  710.         Fax:   x49-711 3704001
  711.         EMail: info@arsnova.stgt.sub.org
  712.  
  713. Languages: Objectworks\Smalltalk by ParcPlace Systems, Inc.
  714.  
  715. Platforms: Unix, PC Windows, Macintosh
  716.  
  717. Features:
  718. - Fully implemented in Objectworks\Smalltalk
  719.   (ArtBASE is delivered with source code)
  720.  
  721. - ArtBASE extents Smalltalk of persistency. Persistent objects are handled the
  722.   same way as transient objects.
  723.  
  724. - Optimistic and pessimistic concurrency control.
  725.  
  726. - Transactions, including long lived transactions
  727.  
  728. - User concept with access restrictions
  729.  
  730. - storing of classes and methods in the database - entire applications 
  731.   may be stored in an ArtBASE database, including the data AND the 
  732.   application classes
  733.  
  734. - Currently, a single user version is available. The Distributed Multi User Server Version
  735.   will be presented at the OOPSLA'93 at Washington D.C. in September 1993 for Unix
  736.   environments and PCs.
  737.  
  738. - Existing applications can be turned to database applications very easily using ArtBASE
  739.  
  740.  
  741. > EasyDB (Objective Systems, Sweden)
  742.  
  743. EasyDB features a (programming language independent) Data Definition
  744. Language (DDL) for the definition of schemas.  It relies on the
  745. Entity-Attribute-Relationship model.  Data Manipulation Languages
  746. (DML) include a Navigational Query language (NQL) embedded in a host
  747. language (C available now, Ada in January '93), and a generic C++
  748. class library.
  749.  
  750. On Schema Evolution (from original survey):
  751. The schema may be freely extended with new items (types, domains,
  752. attributes, entities, relationships etc.). Deletion of items is not
  753. allowed.
  754.  
  755. Data created with an older schema may co-exist with newer data. Old
  756. applications need not be recompiled when the schema is updated.
  757. Attempts by newer applications to access `older' data in an
  758. inconsistent way are detected and reported via an exception handling
  759. system.
  760.  
  761. [Tomas Lundstrom <tomas@os.se>]
  762.  
  763. Objective Systems SF AB (Ericsson)
  764. Box 1128
  765. S-164 22 Kista, Sweden
  766. tel : +46-8-703-4591
  767. fax : +46-8-750-8056
  768. contact: Jaan Habma, jaan@os.se
  769.  
  770.  
  771. > GemStone (Servio Logic)
  772.  
  773. First introduced in 1987, Servio's GemStone is the oldest commercial ODBMS
  774. available today. GemStone is particularly well suited for use in complex
  775. multi-user, multi-platform client/server applications. It supports
  776. concurrent access from multiple external languages, including Smalltalk-80,
  777. Smalltalk/V, C++ and C. GemStone also provides a dialect of Smalltalk as an
  778. internal DML, which can execute methods or entire applications in the
  779. database.
  780.  
  781. Servio also offers GeODE (GemStone Object Development Environment), an
  782. object database application development environment which allows developers
  783. to build complete object applications visually, without writing code. With
  784. GeODE's visual programming tools, programming an application is a matter of
  785. wiring together graphical representations of encapsulated code blocks. A
  786. simple extension mechanism promotes the re-use of code, thereby increasing
  787. the speed of program development. Also, association of application user
  788. interface elements with database objects is established through simple
  789. graphical tools. GeODE applications are stored and run in the GemStone
  790. database, and so are both self-porting and network-aware, and can be
  791. accessed externally from any of the GemStone language interfaces. Because
  792. of GemStone's network architecture, Geode applications can operate easily
  793. in a client/server environment.
  794.  
  795.  
  796.  ==============================================================================
  797.  
  798. GEMSTONE
  799.  
  800. GemStone is a highly scalable client-multiserver database for commercial
  801. applications. GemStone's features include:
  802.  
  803. o  Active Database -- GemStone allows database application developers to
  804.    write methods which are stored and executed directly in the database.
  805.    These methods can be accessed either internally, or from external client
  806.    applications. This can significantly reduce network traffic and allow
  807.    applications to take advantage of the superior compute power of the
  808.    server. This also eliminates the need to rebuild and re-deploy
  809.    applications whenever application or business processing rules change.
  810.    This in turn allows for centralized code development and management,
  811.    architecture-independent code that ports itself to new platforms,
  812.    reduced network usage, and true client/server applications that share
  813.    compute load between client and server machines.
  814.  
  815. o  Concurrent Support for Multiple Languages -- GemStone provides
  816.    concurrent support for applications developed in Smalltalk, C++, C or
  817.    GeODE. All applications, regardless of language, can have simultaneous
  818.    access to the same database objects.
  819.  
  820. o  Flexible multi-user transaction control -- Multiple users can
  821.    operate in the database simultaneously, with a variety of transaction
  822.    control modes available.
  823.  
  824. o  Object-level security -- Authorization control can be applied to any
  825.    object in the database, allowing for fine tuning of object security.
  826.  
  827. o  Dynamic schema and object evolution -- GemStone supports schema
  828.    modification through class versioning and allows full migration of
  829.    objects between versions of their classes with a simple message send.
  830.    Migration is fully customizable and is undoable.
  831.  
  832. o  Production Services -- GemStone delivers the full suite of features
  833.    required in any production-ready networked database including online
  834.    backup, rapid recovery, referential integrity, sophisticated concurrency
  835.    control, and event signals and notifiers.
  836.  
  837. o  Scalability -- In a recent independent benchmark, GemStone scaled to
  838.    support more than 1,000 simultaneous log-ins and 100 concurrent active
  839.    users on a mid-sized SMP server.
  840.  
  841. o  Legacy Gateways -- GemStone incorporates gateways or data bridges
  842.    that allow object applications to integrate legacy data, whether in SQL,
  843.    IMS, VASM or other formats. The level of integration between GemStone
  844.    and legacy data and applications can range from simple query access to
  845.    extensive read-write interoperability.
  846.  
  847.  
  848.  ==============================================================================
  849.  
  850. GEODE
  851.  
  852. GeODE is a comprehensive environment for rapidly designing, building and
  853. deploying production-quality commercial object applications. Its design
  854. promotes code reuse in a team programming environment for increased
  855. productivity. GeODE consists of six main elements:
  856.  
  857. o  Visual Application Manager -- Provides centralized management
  858.    of each application and its component parts, and a namespace for
  859.    addressing known objects.
  860.  
  861. o  Visual Schema Designer -- Allows the development of database schema
  862.    visually, making the process more interactive and intuitive than with
  863.    object-oriented programming languages. It also provides analysis tools
  864.    for examining an existing schema.
  865.  
  866. o  Visual Forms Designer -- The Forms Designer reads GemStone class
  867.    definitions and an associated data dictionary to automatically create
  868.    default forms suitable for simple data entry. These forms can be rapidly
  869.    customized, using a wide selection of user interface components and
  870.    field types, which include image and sound support, and a large set of
  871.    form design aids. The list of field types can be extended interactively.
  872.  
  873. o  Visual Program Designer -- The Visual Program Designer allows developers
  874.    to visually create and modify the behavior of an application without
  875.    having to write code. Programs are created by connecting visual program
  876.    blocks to field blocks drawn from the forms created in the Forms
  877.    Designer. A large collection of predefined program blocks is provided
  878.    with GeODE, and users can extend the catalog in any of a number of
  879.    simple ways. Code-based programming can be integrated routinely.
  880.  
  881. o  Developer Class Library - GeODE comes standard with more than 480
  882.    classes and thousands of methods, and is easily extended for handling
  883.    specialized applications. In a team environment, some programmers can
  884.    develop visual applications while others write new methods that are
  885.    encapsulated into visual program blocks for easy reuse.
  886.  
  887. o  Developer Tools -- GeODE includes tools for debugging, browsing and
  888.    inspecting applications. Included in this set of tools are several
  889.    debuggers, browsers, inspectors, an object clipboard, an image editor,
  890.    and a code profiler for performance analysis.
  891.  
  892.  
  893.  ==============================================================================
  894.  
  895. PLATFORMS
  896.  
  897. GemStone release 3.2 and GeODE 2.0 and all language interfaces are
  898. available for UNIX workstations and servers from SUN, HP, IBM, Sequent, and
  899. DEC. Client-only support is available in a number of languages for Windows
  900. 3.1, OS/2 and Macintosh. Servio is an active member in the Object
  901. Management Group and the ANSI Smalltalk standardization committee. Servio
  902. supports SUN ODMG, ANSI C++ and intends to comply fully with the emerging
  903. standards.
  904.  
  905.  ==============================================================================
  906.  
  907. REFERENCES
  908.  
  909.   [Maier, et al. 84] D. Maier, J. Stein, A. Otis, A. Purdy, ``Development
  910.   of an object-oriented DBMS'' Report CS/E-86-005, Oregon Graduate Center,
  911.   April 86 - ACM 0-89791-204-7/86/0900-0472
  912.  
  913.   R.G.G. Cattell: Object Data Management - Object-Oriented and Extended
  914.   Relational Database Systems; Addison-Wesley. ISBN 0-201-53092-9
  915.  
  916.   Robert Bretl, David Maier, Allan Otis, Jason Penney, Bruce Schuchardt,
  917.   Jacob Stein, E. Harold Williams, Monty Williams. "The GemStone Data
  918.   Management System." Chapter 12 of "Object-Oriented Concepts, Databases
  919.   and Applications", by Kim and Lochovsky.
  920.  
  921.  
  922.  ==============================================================================
  923.  
  924. CONTACTS
  925.  
  926.  === Headquarters - San Jose ====
  927.  
  928. Servio Corporation
  929. 2085 Hamilton Avenue
  930. Suite 200
  931. San Jose  CA  95125
  932.  
  933. Tel: 800-243-9369
  934. Tel: 408-879-6200
  935. Fax: 408-369-0422
  936.  
  937.  === Chicago ====
  938.  
  939. Servio Corporation
  940. 8410 Bryn Mawr
  941. Suite 400
  942. Chicago  IL  60631
  943.  
  944. Tel: 312-380-1310
  945. Fax: 312-380-1308
  946.  
  947.  ===  New York ====
  948.  
  949. Servio Corporation
  950. 1120 Avenue of the Americas
  951. 4th Floor
  952. New York  NY  10036
  953.  
  954. Tel: 212-626-6680
  955. Fax: 212-626-6684
  956.  
  957.  === Dallas ====
  958.  
  959. Servio Corporation
  960. 14875 Preston Road
  961. Suite 550
  962. Dallas  TX  75240
  963.  
  964. Tel: 214-980-7073
  965. Fax: 214-980-2949
  966.  
  967.  === Europe/UK ====
  968.  
  969. Servio UK
  970. Criterion House
  971. Beauchamp Court, Victors Way
  972. Barnet  EN5 5TZ  England
  973.  
  974. Tel: +44 81 447-0800
  975. Fax: +44 81 447-0577
  976.  
  977.  === Japan ====
  978.  
  979. Servio Corporation
  980. Daito-Eiwa Building, 7F
  981. 5-11 Nihonbashi-Hakozakicho
  982. Chuo-ku  Tokyo 103  Japan
  983.  
  984. Tel: +81 3 3660-1910
  985. Fax: +81 3 3663-3287
  986.  
  987.  =====================
  988.  === Distributors ====
  989.  =====================
  990.  
  991.  === Germany, Austria, Switzerland ====
  992.  
  993. ObjectOriented System Technologies
  994. Baroper Str. 337
  995. Dortmund  50  W-4600
  996. Germany
  997.  
  998. Tel: +49 231 975 990
  999. Fax: +49 231 975 99-20
  1000.  
  1001.  === Japan ====
  1002.  
  1003. Japan Information Processing Co., Ltd.
  1004. 6-7 Kabutocho, Nihonbashi
  1005. Chuo-ku  Tokyo 103  Japan
  1006.  
  1007. Tel: +81 3 3668-6170
  1008. Fax: +81 3 3668-1428
  1009.  
  1010.  ---
  1011.  
  1012. Nexus Technology K.K.
  1013. Suite 901
  1014. Botan 3-11-1
  1015. Koto-ku  Tokyo 135  Japan
  1016.  
  1017. Tel: +81 3 3660-1910
  1018. Fax: +81 3 3663-3287
  1019.  
  1020.  === Taiwan ====
  1021.  
  1022. Anco Technologies
  1023. 11-1F, 76 Tun Hwa S. Road, Sec. 2
  1024. Taipei
  1025. Taiwan, R.O.C.
  1026.  
  1027.  === Italy ====
  1028.  
  1029. Etnoteam S.P.A.
  1030. Via Adelaide Bono Cairoli 34
  1031. Milano  20127  Italy
  1032.  
  1033. Tel: +39 2 261 621
  1034. Fax: +39 2 261 10755
  1035.  
  1036.  === England ====
  1037.  
  1038. AI International Ltd.
  1039. 1 Parkview Road
  1040. Berkhamsted
  1041. Herts  HP4 2EY  England
  1042.  
  1043. Tel: +44 442 876 722
  1044. Fax: +44 442 877 997
  1045.  
  1046.  ==== Mexico ====
  1047.  
  1048. TEIX, Sistemas de Informacion
  1049. Estrategica S.A. de C.V.
  1050. Antonio M. Anza No. 43
  1051. Col Roma  Mexico D.F.  06700
  1052.  
  1053. Tel: +52 5 564-7146
  1054.  
  1055.  
  1056. > ITASCA
  1057.                        ITASCA ODBMS V2.2
  1058.  
  1059.                       Itasca Systems, Inc.
  1060.                        7850 Metro Parkway
  1061.                       Minneapolis, MN 55425
  1062.                         sales@itasca.com
  1063.                          (612) 851-3155
  1064.  
  1065.                           Sandy Miezwa
  1066.                          (612) 851-3169
  1067.  
  1068. Introduction
  1069.  
  1070. Itasca Systems develops, markets, and supports ITASCA, a distributed 
  1071. active object database management system and related tools. The initial 
  1072. research work for ITASCA occurred in the Object-Oriented and Distributed 
  1073. Systems Lab at the Microelectronics and Computer Technology 
  1074. Corporation (MCC) in Austin, Texas. The research was known as the 
  1075. ORION prototypes. 
  1076.  
  1077. The ITASCA Distributed ODBMS is a language neutral, full-featured, active 
  1078. object database that supports data access from various object
  1079. languages. ITASCA allows clients to transparently access data that is
  1080. distributed among multiple servers.  ITASCA supports full dynamic schema
  1081. modification that can be performed during any phase of the software
  1082. lifecycle.  Applications written in dissimilar and incompatible languages,
  1083. such as C++ and CLOS, share objects through ITASCA. ITASCA stores methods
  1084. inside the database, promoting reusability and maintainability.  The only
  1085. commercial ODBMS based upon the MCC Orion technology, ITASCA is considered
  1086. by many to be the most feature-rich ODBMS on the market today.
  1087.  
  1088. This overview describes release 2.2 of the ITASCA Distributed Object 
  1089. Database Management System. It describes how ITASCA functions, 
  1090. outlines its implementation features, and explains some of the system 
  1091. benefits. 
  1092.  
  1093.  
  1094. History of ITASCA
  1095.  
  1096. ITASCA is based on a series of object database research prototypes. Work 
  1097. on these prototypes began in 1985 at the Microelectronics and Computer 
  1098. Technology Corporation (MCC) Object-Oriented and Distributed Systems 
  1099. Laboratory. MCC released the first prototype, ORION-1, in May, 1987, as 
  1100. a single-user system. MCC extended ORION-1 to the ORION-1SX 
  1101. prototype system and released it to the shareholder companies in April, 
  1102. 1988. ORION-1SX was a multi-user system with a multi-client, single 
  1103. server architecture. The third prototype, ORION-2, introduced a distributed, 
  1104. object-oriented architecture for a multi-user environment. MCC released 
  1105. the third prototype to shareholder companies in July, 1989. ORION-2 has a 
  1106. multi-client, multi-server architecture. Having met its objectives, MCC 
  1107. stopped all work on ORION at that time. Over five million dollars was spent
  1108. for the three generations of prototypes.
  1109.  
  1110. The ITASCA product is an extension and commercialization of the ORION-2
  1111. prototype from MCC. Itasca Systems has added major enhancements and
  1112. features, improved the performance, and strengthened the code. It now runs
  1113. on UNIX systems from multiple vendors. ITASCA is an industrial-strength,
  1114. documented product, fully supported by Itasca Systems, Inc. Itasca Systems
  1115. continues to develop tools and other products to work with ITASCA.
  1116.  
  1117.  
  1118. Overview
  1119.  
  1120. ITASCA employs a distributed architecture with private and shared objects 
  1121. spread across UNIX-based computers on a local-area network. The 
  1122. ITASCA model follows the object-oriented view that uniformly models any 
  1123. real-world entity as an object. Each object has a unique identifier along with 
  1124. a state and behavior. Attributes represent the state of an object. Methods 
  1125. (code) define the behavior of an object. A class object collects objects that 
  1126. share the same set of attributes and methods. Subclasses derive from 
  1127. existing classes. The resulting schema, or database definition, is a class 
  1128. hierarchy. Each subclass inherits all the attributes and methods of its 
  1129. superclasses. ITASCA supports multiple inheritance. A subclass may derive 
  1130. from more than one superclass. 
  1131.  
  1132. One of the breakthroughs of object-oriented technology is the reusability of 
  1133. code. ITASCA allows for the active management of both reusable code and 
  1134. data in an integrated system. Developers may write applications in C++,
  1135. CLOS, C or Common Lisp. This means ITASCA is language neutral. Objects 
  1136. stored using one programming language can be accessed by other 
  1137. programming languages. It also means an application program need not be
  1138. written in an object-oriented language. 
  1139.  
  1140. The ITASCA database management system has features belonging to most any 
  1141. database system. This includes persistent storage for data and schema, 
  1142. concurrency control and locking, transaction management, multiple 
  1143. security levels, and logging and recovery for both CPU and disk media 
  1144. failure. Additional features of ITASCA include dynamic schema 
  1145. modification, long-duration transactions, shared and private databases, 
  1146. distributed version control, distributed transaction management, distributed 
  1147. query management, distributed change notification, object migration, and 
  1148. an extensible architecture.
  1149.  
  1150. Shared and private databases exist in a distributed environment in ITASCA. 
  1151. The shared database is distributed across workstations (sites) in a network. 
  1152. An ITASCA server controls the partition of the shared database at each site. 
  1153. ITASCA clients provide transparent access to the various partitions of the 
  1154. shared database. The architecture allows any number of private databases at 
  1155. each distributed database site. Data can move between private and shared 
  1156. databases. Private databases allow private data that is not shared with other 
  1157. users of the database.
  1158.  
  1159. ITASCA stores the schema redundantly at each site to improve 
  1160. performance. The schema storage also includes code in the form of 
  1161. methods. Management of schema updates is automatic for all sites. This 
  1162. includes sites that were off-line during any changes. Automatic distribution 
  1163. of schema changes, including method code changes, simplifies database 
  1164. administration.
  1165.  
  1166. ITASCA stores each instance of data in one site. The system or a user may 
  1167. move the data from one site to another to improve data locality. Access to 
  1168. moved data remains transparent. There is no need for a user or application 
  1169. to know the specificlocation of data in the ITASCA distributed database. 
  1170. ITASCA will automatically find the location of the data. This simplifies 
  1171. distributed application development. The developer can rely on ITASCA 
  1172. finding data in the distributed database.
  1173.  
  1174. No single site acts as a master site, thus ITASCA's architecture has no 
  1175. single point of failure. ITASCA has neither a central data server nor a 
  1176. central name server. This is important for maintaining a database system 
  1177. with high availability in a networked workstation environment.
  1178.  
  1179. ITASCA supports dynamic schema modification to create a flexible 
  1180. environment for changing or customizing a database system. Authorized 
  1181. users can add and remove attributes or change the subclass/superclass 
  1182. relationship at any time. Authorized users can also add or remove partitions 
  1183. of the shared database at any time. All this can be done interactively without 
  1184. affecting other parts of the ITASCA database at the time changes occur to 
  1185. the schema. There is no need to "bring the system down" or off-load/reload 
  1186. data to restructure the database. Dynamic schema modification can 
  1187. significantly reduce maintenance costs. It also is useful in environments 
  1188. where change to data definitions are normal or relatively frequent.
  1189.  
  1190. ITASCA has a sophisticated security authorization technique tied to the 
  1191. class hierarchy. It supports both positive and negative authorizations at any 
  1192. level in the class hierarchy. For example, granting access to all objects but 
  1193. one requires only two authorizations: a global grant followed by a specific 
  1194. denial. Authorization extends to classes, instances of classes, attributes, 
  1195. and methods. Also, inheritance of authorization reduces the work of database 
  1196. administration. 
  1197.  
  1198. Long-duration transactions allow users to check objects out of the shared, 
  1199. distributed database into their private databases. Users can then change the 
  1200. objects in the private databases without affecting the shared database or 
  1201. other users. These changes can be committed to the private database. Then, 
  1202. at any later time, the user can check the updated object or objects back into 
  1203. the shared database.
  1204.  
  1205. ITASCA supports version control of objects. A new version of an object 
  1206. promotes the original or parent object to restrict further changes to the 
  1207. parent. ITASCA also supports alternate versions such that multiple versions 
  1208. can have the same parent. Promoting an object version to a released status 
  1209. restricts any deletion of the object. ITASCA uses generic versions to 
  1210. dynamically reference the most recent or default version of an object 
  1211. without any intervention by a user or application.
  1212.  
  1213. Change notification in ITASCA is either flag-based or message-based. 
  1214. Flag-based notification will identify an updated object upon querying the 
  1215. object for such information. It is a passive notification scheme. Message-
  1216. based notification, on the other hand, is an active notification scheme. It 
  1217. will execute a method (or code) upon an update or other change to an object. 
  1218. Such methods can send mail messages or invoke other methods or 
  1219. programs. 
  1220.  
  1221. Memory management in ITASCA uses both page and object buffers. 
  1222. ITASCA has a traditional database page buffer scheme that contains pages 
  1223. with multiple objects. Desired objects move from the page buffer to an 
  1224. object buffer. The object buffer then provides ITASCA with enhanced in-
  1225. memory performance because it contains only frequently-referenced 
  1226. objects. 
  1227.  
  1228.  
  1229. > Matisse
  1230.  
  1231. OODBMS FEATURES LIST:
  1232.  
  1233. An Industrial Strength Open Semantic Object Database
  1234.  
  1235. Performance
  1236. -       Symmetric, Fine Grain, Multi-Threaded Architecture
  1237. -       Parallel and Asynchronous Disk I/O
  1238. -       Automatic Disk Optimization through Dynamic Clustering
  1239. -       High Speed OLTP Environment
  1240. Reliability
  1241. -       24 Hour - Mission Critical Operation
  1242. -       Media Fault Tolerant (Object Replication)
  1243. -       Transparent On-line Recovery
  1244. Database Administration
  1245. -       Full On-line Administration (No Down Time)
  1246. -       On-line Incremental or Full Back-Up
  1247. -       Dynamically Increase Database Size -   On-line
  1248. -       Full On-line Monitoring
  1249. Data Management and Consistency
  1250. -       Dynamic Schema Evolution
  1251. -       Consistent Database Reads without Locking
  1252. -       Historical Versioning, both Schema and Data Objects
  1253. -       Built-in Enforced Referential Integrity
  1254. -       Object Level Implicit or Explicit Locking
  1255. Scalability
  1256. -       Hundreds of Concurrent On-line Users
  1257. -       Hundreds of Gigabytes Per Database
  1258. -       From Few Bytes to Four Gigabytes for Each Object
  1259. -       Up to Four Giga-objects Per Database
  1260. Object Model
  1261. -       Full Object Oriented Model
  1262. -       User Extensible Object Meta-Schema
  1263. -       Support for Complex, Highly Dynamic, Variable Sized Objects
  1264. -       Multiple Inheritance
  1265. Intelligent Objects
  1266. -       Triggers at Object, Attribute, or at Relationship Level
  1267. -       Consistency Rules at Object, Attribute, or at Relationship Level
  1268. -       Customizable Intelligent Object Indexing
  1269. -       Automatic Inverse Relationships
  1270. Open Systems
  1271. -       Open C, C++ API
  1272. -       Supports Any Commercial Development Tool and Language
  1273. -       No Proprietary Tool Required
  1274. -       Heterogeneous Cross Platform Client/Server Architecture
  1275.  
  1276. For Information on MATISSE, Contact one of the following offices:
  1277.  
  1278. USA:
  1279. ODB, an Intellitic International Company
  1280. 238 Broadway
  1281. Cambridge, MA  02139
  1282. Phone:(617) 354-4220
  1283. Fax: (617) 547-5420
  1284. email:  info@odb.com
  1285.  
  1286. EUROPE:
  1287. INTELLITIC INTERNATIONAL
  1288. 12-14 rue du Fort de Saint-Cyr
  1289. Montigny-le-Bretonneux
  1290. 78182 Saint Quentin en Yvelines Cedex France
  1291. Phone:   33(1) 30.14.54.30
  1292. Fax:    33 (1) 30.14.54.40
  1293.  
  1294. JAPAN:
  1295. SGN CO. LTD.
  1296. Urban Toranomon Building
  1297. 16-4 Toranomon
  1298. Minato-Ku Tokyo 105 Japan
  1299. Phone:   81 (3) 3593.34.31
  1300. Fax:   81 (3) 3593.34.32
  1301.  
  1302.  
  1303. > NeoAccess
  1304.  
  1305. A cross-platform object-oriented database engine based on C++. It allows
  1306. developers to embed the power of a fully-functional object-oriented database
  1307. system into their applications. All of the data contained in the database,
  1308. including indices, can be in a single file, so users can treat a database
  1309. file as they would a standard document file. The programming model is
  1310. designed to keep visible complexity to a minimum while providing a
  1311. feature-rich foundation on which to build and enhance applications.
  1312.  
  1313. NeoAccess has taken a different approach toward the issues surrounding object
  1314. persistence than have other solutions that have been offered. We believe that
  1315. objects should be viewed as having a set of properties with a pliable state.
  1316. With NeoAccess persistent objects are provided with persistence and sharing
  1317. properties. These properties allow objects to maintain an association with a
  1318. file. This association, which can be built and broken freely, allowing
  1319. objects to migrate freely between disk and memory. The API to these
  1320. properties address issues such as adding or deleting the object from a file,
  1321. sorting and indexing, locating and later freeing the object in memory, object
  1322. sharing, and maintaining relationships between objects.
  1323.  
  1324. NeoAcces
  1325. s with has been fully integrated into standard application frameworks such as
  1326. Borland's ObjectWindows and MacApp 3.0 and the THINK Class Library on the
  1327. Macintosh. A single source tree can be used to build the engine in all
  1328. development environments. Database files are binary-compatible across
  1329. platforms so users on different types of machines can share data without
  1330. conversion.
  1331.  
  1332. Contact:
  1333. Bob Krause
  1334. NeoLogic Systems
  1335. 1373 Third Avenue
  1336. San Francisco, CA 94122
  1337. (415) 566-9207
  1338.  
  1339.  
  1340. > O2 (INRIA/O2 Technology)
  1341.  
  1342. This is an entry on schema evolution.  General papers on O2 are included.
  1343.  
  1344. We have implemented in O2 schema updates in our first release but
  1345. without NO IMPACT on the database (we have a design to implement
  1346. deferred update, but it is a paper design). However, users manage to
  1347. convert their instances by hand, using their O2 programs written
  1348. themselves, and with the aid of the following tools:
  1349.  
  1350. 1- There is a set of predefined classes whose instances contain
  1351.    objects representing a schema (i.e., a Meta-schema). These classes
  1352.    may be used in a conversion program, they may even be extended by
  1353.    the programmer.
  1354.  
  1355. 2- There is a save-restore program that allows to take an O2 database,
  1356.    save it on a file or a tape in a logical way (i.e., independent of
  1357.    the physical format of objects on disk), and restore it again on a
  1358.    (perhaps new release) of the system, in an empty database.
  1359.    Currently, when saving a database its schema is also saved. The
  1360.    next extension to this save/restore program will be to save the
  1361.    database without saving its schema, and then restore the database
  1362.    on a new version of that schema. The restore program will be able
  1363.    to perform automatically some conversions like "add attribute" or
  1364.    "delete attribute".
  1365.  
  1366.  
  1367. Schema updates with impact on the database will be implemented in future 
  1368. releases.
  1369.  
  1370. [Fernando Velez <fernando@o2tech.fr>]
  1371.  
  1372.  
  1373. For more information on O2, consult the following REFERENCES:
  1374.  
  1375.         Francois Bancilhon, Claude Delobel, Paris
  1376.         Kanellakis.  "Building an Object-Oriented Database
  1377.         System: The Story of O2".  Morgan Kaufmann Series
  1378.         in Data Management Systems, San Mateo, Calif., 1992.
  1379.         
  1380.         F. Bancilhon, G. Barbette, V. Benzaken, C. Delobel,
  1381.         S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard,
  1382.         and F. Velez.  "The Design and Implementation of
  1383.         O2, and Object-Oriented Database System".
  1384.         Advances in Object-Oriented Database Systems,
  1385.         Springer Verlag. (Lecture Notes in Computer Science
  1386.         series, Number 334.)
  1387.  
  1388.         C. Lecluse, P. Richard, and F. Velez. "O2, an
  1389.         Object-Oriented Data Model".  Proceedings of
  1390.         SIGMOD88.  Also appears in Zdonik and Maier,
  1391.         "Readings in Object-Oriented Database Systems",
  1392.         Morgan Kaufmann, 1990.
  1393.  
  1394.  ==== Corporate headquarters:
  1395. O2 Technology
  1396. 7 Rue du Parc de clagny
  1397. 78035 Versailles Cedex
  1398. France
  1399. tel : 33 1 30 84 77 77
  1400. fax : 33 1 30 84 77 90
  1401.  
  1402. [They have many other contacts worldwide]
  1403.  
  1404.  
  1405. > Objectivity/DB (Objectivity)
  1406.  
  1407. Introduction:
  1408.  
  1409. Objectivity/DB has a fully distributed client/server architecture that
  1410. transparently manages objects distributed across heterogeneous environments and
  1411. multiple databases.  It provides an application interface that uses transparent
  1412. indirection to ensure integrity and provides a single logical view of all
  1413. information, with all operations working transparently on any database on the
  1414. network, with scalable performance as users and objects increase.  A
  1415. higher-level Object Definition Language (ODL) is available as well as a C
  1416. functional interface, integrated C++ interface, and SQL++.
  1417.  
  1418.  
  1419. Objectivity/DB
  1420.  
  1421. Objectivity/DB [Reference:  Technical Overview, Objectivity, 1993], a product
  1422. of Objectivity, Inc. of Menlo Park, CA, provides an integrated C++ programming
  1423. interface with an emphasis on the DBMS engine for robustness and scalability
  1424. from workgroups to enterprise-wide production applications.  In production use
  1425. today with more than 50,000 end users licensed, it supports a fully
  1426. distributed, rather than central-server, architecture, with all operations
  1427. working transparently over a mixture of multiple databases, schemas, users, and
  1428. computers, and over heterogeneous hardware, operating systems, and networks. 
  1429. The language interface includes a C++ class library interface, soon to be ODMG;
  1430. a C function library; and SQL++, supporting query predicates with either SQL or
  1431. C++ syntax, interactively or programmatically.  Over forty administrative and
  1432. GUI tools provide both an interactive and programmatic interface, and a
  1433. messaging backplane allows third party tools integration at four different
  1434. levels, with a list of partners at all levels.
  1435.  
  1436. One of the key architectural concepts of Objectivity/DB is an object reference
  1437. mechanism that ensures data integrity.  Unlike traditional ODBMSs that use
  1438. direct pointers, which become invalid after commit and hence lead to crashes
  1439. and corrupt databases, Objectivity/DB uses an indirection to guarantee safe
  1440. reference.  Transparent to the user, this indirection requires an extra test
  1441. and pointer dereference, or a couple of cycles, which is not measurable in most
  1442. applications.  However, it ensures integrity of all references, even across
  1443. transaction boundaries, resulting in production quality robustness.  Also, it
  1444. provides object level granularity for the object manager, allowing it to move,
  1445. cluster, and swap objects as necessary, one of the keys required for
  1446. scalability in objects and users.  Finally, it allows object-level granularity
  1447. for current features, such as heterogeneity and versioning, and future
  1448. extensions, such as object-level security.
  1449.  
  1450. A higher-level Object Definition Language (ODL) is provided that allows
  1451. declaration of modeling concepts such as bi-directional associations, behavior
  1452. of associations between objects as they version (move, copy drop), and
  1453. propagation of methods across associations.  These then result in automatically
  1454. generated methods and declarations for both C++ and C.  The standard C++ API
  1455. allows application programmers to work with any standard compilers and
  1456. debuggers, with no extra pre-processors, providing ODBMS capabilities via
  1457. overloading C++ operators (new, ->, etc.), and declarations via provided
  1458. classes (for references, etc.).
  1459.